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Abstract 

Johannsen, W M Transaction models for federative distributed database systems. Future Generation Computer Systems 7 
(1991/92) 329-337. 

Federative Distributed Database System (FDDBS) are composed out of independent nodes in a computer network. Each 
server node comprises a Database Management System (DBMS) offering services of different quality to the outside world, 
i.e. remote users at client systems. In addition local services are offered to local users. Server nodes are independent from 
other notes. This reflects the characteristic of an dynamically growing and shrinking federation of databases in open systems. 
Typically user applications are distributed and should be supported by management functions that guarantees certain service 
quality. The most important are atomicity and isolation. Units of works that provides such characteristics are distributed 
transactions. 

In this paper we discuss the advantages and disadvantages of two transaction models with respect to FDDBSs. Beside 
traditional distributed (global) transactions we consider a model based on the Saga approach. We show how both can be 
integrated in one environment. The approach taken increases node autonomy and allows for a higher degree of parallelism 
* without loss of the advantages of traditional distributed transactions. 

Keywords. Distributed transactions; node autonomy; federative systems; scrializability; sagas. 



1. I nt rod net ion and overview 

One of the significant characteristics of future 
op en systems will be the ability to support dis- 
tributed database applications. The databases to 
be accessed will be managed by heterogeneous 
Database Management Systems (DBMS) running 
in open systems environments. Each node in such 
a network requires a great amount of node au- 
tonomy with respect to availability, security, 
defining access rights and controlling of external 
(remotely) requested applications [1]. We will 
concentrate on execution autonomy, that is the 
freedom of a node to run an application on a 
node without becoming dependent on other 
nodes. Refer to [2] for an architecture based on 
ISO/OS! protocols that overcomes network and 
database heterogeneity. 

Data maintained by different Database Man- 
agement Systems (DBMS) is independent from 



each other. Consequently no consistency con- 
straints beside such required by a running appli- 
cation exists across network node boundaries. 

One more important characteristic besides 
heterogeneity and autonomy will be the absence 
of a global database schema that would allow for 
defining integrity constraints or maintaining ref- 
erential integrity across nodes. Interconnected 
database systems with such characteristics form a 
Federative Distributed Database System (FD- 
DBS). The term Federation refers to the rela- 
tively high degree of autonomy and low degree of 
interdependences between nodes. 

Distributed applications in a FDDBS will rely 
on distributed transactions. Because of the poten- 
tial conflict between autonomy requirements and 
the realization of traditional distributed transac- 
tions, new transaction execution strategies and 
transaction models have to be considered. 

The common approach to implement dis- 
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tributed transactions is based on a combination 
of Two-Phase-Lockine (2PL) [3] and Two-Phase 
Commit (2PC) [4]. The first provides for local 
concurrency control and the latter for coordi- 
nated termination of subtransactions. It is as- 
sumed here thai a so called Global Transaction 
(GT) consists of subtransactions (limited to one 
per node). The combination of 2PL/2PC pro- 
vides global serializability [5J. 

Beside this traditional approach, new transac- 
tion models and execution strategies are being 
designed. In [6]. [7] the synchronization goal is 
relaxed by introducing quasi serializable histories 
of operations. This is achieved when local trans- 
actions of a node are not considered as "candi- 
dates for synchronization with subtransactions of 
distributed Global Transactions. 

Several approaches have been introduced to 
relax the 'isolation' between distributed transac- 
tions. The best known is the Saga approach [8]. 
Subtransactions of Sagas are executed indepen- 
dently. The results of subtransactions are made 
visible before the last subtransaction of a certain 
Saga is executed successfully. Thus node auton- 
omy is increased since local data can be accessed 
independently from the state of other nodes. In 
case of failures compensating transactions are 
used for recovery. Related approaches are S- 
Transactions [9] and Migrating Transactions [10]. 

In this paper we introduce the concept of 
Global Transaction Procedures (OTP). GTPs are 
global units providing for semantic atomicity [11]. 
Subtransactions of different GTPs are executed 
completely isolated from each other whereas at 
the global level the isolation is reduced. GTPs are 
integrated with GTs in order to overcome major 
drawbacks of Sagas. In particular it is the restric- 
tion to 'simple' distributed applications that is 
overcome by the integration of GTPs with GTs in 
a single environment. As a result the integrated 
approach allows for execution of complex trans- 
actions based on traditional GTs. The simpler 
semantics (ordering, reservations, preparing 
schedules etc.) are based on GTPs. 

The section following this overview gives an 
outline of our architecture model of an open 
FDDBS. Then Global Transactions and serializ- 
ability requirements are discussed. Global Trans- 
action Procedures are discussed next. Our ap- 
proach of integrating these transaction models is 
presented in the final part of the paper. 



2. The architect u ml model of" ;in open feci era live 
database .system 

According to the client/ server model data- 
base server systems in our environment offer ser- 
vices accessible by client systems. The client sys- 
tems (workstations and mainframes) may or may 
not maintain their own database systems. 
Database server systems are administered by hu- 
man administrators responsible for an adminis- 
trative area that may span several server systems. 
For example in Fig. I an administrative area 
could include all servers (S) within a certain Lo- 
cal Area Network (e.g. NW 3). Such an area 
consisting of several database systems may form a 
distributed database system of its own. In the 
latter case we assume that a single service inter- 
face for remote users and a single global concep- 
tual schema that help to maintain integrity con- 
straints is provided for each administrative area. 
Databases in open systems are accessed by dis- 
tributed applications. The number of databases 
accessible by remote users in such a configuration 
changes dynamically. Databases can be made ac- 
cessible and removed at any time. No global 
administration is responsible for maintaining the 
whole system. Heterogeneity (Fig. 2) is overcome 
by standardized software components in open 
systems. Communication protocols standardized 
by ISO according to the reference model for 
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Fig. l. Federative Distributed Database System: The figure 
shows an example configuration of a FDDBS consisting of 
client (C) user nodes and server tS) database system nodes. 
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Fig. 2. Open Systems: Distributed applications arc executed 
without support of global centralized components. 



Open System Interconnection (OSI) [12] like Re- 
mote Database Access (RDA) [13] and Transac- 
tion Processing (TP) [14] play a key role here [2], 
The a priori decentralized character of open sys- 
tem environments prohibits the application of 
centralized control functions as GM components. 
The more natural solution is to decentralize con- 
trol software as much as possible. 

Obviously data stored in different databases in 
open systems is independent from each other. 

Server nodes running a DBMS comprising 
components for local transaction management 
(LTM) and local data management (LDM). In 
addition, an interface for global transaction sup- 
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Fig. 3. Node Architecture: Each Node provides for a 
Two-Phase-Commit (2PC) protocol interface for subtransac- 
tions of Global Transactions. The coordination is in the 
responsibility of the client nodes. 



port (i.e. a Two-Phase-Commit Protocol inter- 
face, 2PC) has to be provided. This interface is 
connected to the local communication subsystems 
(Fig. 31 

Servers involved in a distributed application do 
not cooperate directly. However, we do not re- 
strict a server from acting as a client with respect 
to other servers thereby forming a tree like trans- 
action structure [14]. 

Client nodes act as initiators and coordinators , 
responsible for one or more applications access- 
ing remote server databases. In general a Global 
Transaction is initiated and controlled by a client 
component. To fulfill this task the client might 
ask for more services than are provided by 
databases to be accessed. In particular dictionary 
services are needed to allow a certain degree of 
location transparency. 

Client applications are global. This is by means 
of accessing more than one remote system at a 
time. 

Based on the assumptions above, we list the 
main characteristics of our architectural model of 
an open FDDBS: 

1. Decentralized control functions: 

• Each (human) database administrator is re- 
sponsible for only a subsection of all 
database systems accessible by a global (dis- 
tributed) application. 

* Transaction management is done by the lo- 
cal database management systems in cooper- 
ation with coordinators of global applica- 
tions. Coordination functions are needed for 
termination of Global Transactions. 

2. Independence of coordinators: Coordinators do 
not exchange messages. 

3. Local DBMSs support of transaction termina- 
tion: An interface for supporting the Two 
Phase Commit protocol is to be provided at 
each local DBMS. In case different transaction 
models are applied additional termination 
support is required. Termination support is 
the only extension to existing database man- 
agement systems that has to be provided in 
order to integrate databases into a federation. 

4. Treating subtransactions of Global Transac- 
tions: Sub-transactions of Global Transactions 
are treated the same way as local transactions. 

Both types of transactions are managed by 
the same local concurrency control mecha- 
nism. Therefore from a local point of view no 
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differences between local transactions and 
subtransactions exists. 

5. Execution Autonomy: Local database systems 
are not requested to operate all the time. 

6. Independence of data: Data maintained by lo- 
cal databases is considered to be independent 
from each other. 

We are not considering replicated data in our 
model. This is due to the fact that we see a open 
system as a dynamically growing and shrinking 
collection of independent database systems. 



3. Global transactions 

A widely accepted method of realizing Global 
Transactions is the combination of Two-Phase- 
Locking (2PL) and Two-Phase-Commit (2PC) 
Protocols. 2PL protocols provide for local serial- 
izable schedules. In our mode! local transactions 
and subtransactions of -global transactions are 
executed concurrently at the same node. Thus 
they are treated by the same concurrency control 
and recovery system at each local database. 

Global consistency is preserved by coordinated 
termination of global transactions. Termination 
of Global Transactions is supported by the 2PC 
protocol. The 2PC/2PL combination guarantees 
that locks held by the local concurrency control 
components on behalf of a subtransaction of a 
Global Transaction are not released before the 
coordinator explicitly orders to do so. The coordi- 
nator observes the state of all subtransactions 
and ensures that each one can be terminated 
successfully (commit) only if all other subtransac- 
tions are also ready to commit. 

It is well known that the, 2PC/2PL combina- 
tion produce global serializable schedules. It is 
obvious that at each node the same relative order 
of subtransactions is produced. Otherwise a cycle 
in the dependency graph that could lead to a 
distributed deadlock would occur [15]. This is 
true even for the combination of 2PC and local 
optimistic concurrency control [5]. 

Nevertheless, the use of 2PC protocol has some 
drawbacks which are especially harmful in open 
systems. Local DBMSs are made to wait for each 
other for locally unknown time periods because 
of the 2PC voting procedure. In addition dis- 
tributed deadlock may occur. 
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Fig. 4. Autonomy: Between tr and 1c the server has to wait 
lor the decision of the coordinator. 



Autonomy: As explained before the 2PC pro- 
tocol is used to coordinate termination of Global 
Transactions. A Global Transaction can only be 
committed if all subtransactions on all nodes have 
sent a ready message {Fig. 4). Otherwise all 
subtransactions have to be aborted. This implies 
that servers wait for each other, fhe latest sub- 
transaction entering the ready state determines 
the time when the decision to commit can be 
made by the coordinator. Until that time all other 
servers have to wait. The servers are not allowed 
in this state to release locks or cancel the sub- 
transactions based on their own decision. In other 
words they are loosing the autonomy of executing 
applications on data locked by waiting subtrans- 
actions of Global Transactions. 



4. Serial izabi I ity requirements in open systems 

Global serializabiiity for most applications is a 
sufficient correctness criterion. It guarantees that 
the result of a series of Global Transactions is the 
same as if they would be executed in strong 
(arbitrary) serial order. 

Strict isolation of transactions is the main pre- 
requisite to gain this property. Isolation of Global 
Transactions prevents the reading of any uncom- 
mitted results of a certain transaction by other 
transactions. 

It has often been argued that global serializ- 
abiiity is too strong a criterion for correctness in 
federative distributed databases [6,8,10,16]. The 
main reason for this is the reduced execution 
autonomy resulting from using the 2PC protocol 
during transaction termination. The approaches 
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suggested so far to overcome this are based mostly 
on scma/itic atomicity [11]. 

Although the proposed solutions increase the 
node autonomy they are restricted to a small 
class of applications of rather simple semantics 
(ordering, reservations, preparing schedules etc.) 
[16]. This is because the execution of Global 
Transactions is controlled by execution plans 
specified by a dedicated language or other de- 
scription techniques. The execution plans include 
instructions for subtransaction execution order, 
descriptions of allowed interleaving transactions 
and rules for the case of a failure. 

In our approach we also claim that in cases 
where the databases are independent from each 
other, global serializability is not needed for all 
applications. Here the most important property 
of global transactions is atomicity instead of isola- 
tion. Although reduced isolation implies loss of 
global serializability, local serializability is still 
required for subtransactions and local transac- 
tions. 

Example. A machine producing company as- 
sembles products of parts produced by subcon- 
tracted. Each company producing parts runs a 
database system that allows for remote access. In 
order to keep the production plant supplied opti- 
mally with required pans an automatic ordering 
system is used. The system orders parts by using 
remote databases controlled by the producing 
companies. The restriction is: an application is 
considered to be successful only if all pans needed 
for a machine to be assembled can be ordered. 
This is to reduce storage requirements for the 
company as much as possible. As a consequence 
the application has to be executed as an atomic 
unit of work. In case a requested part is not 
available an alternative company (database) is 
used. In case no alternatives are at hand the 
orders already done are canceled. 

When analyzing this example (characteristics 
are adopted from [17]) it is obvious that the 
application requirements could be met by an 
atomic Global Transaction. The transaction prop- 
erties make sure that cither each order issued by 
the company is successfully executed or none is 
valid. However, since the accessed databases are 
completely independent from each other no need 
to isolate concurrent global applications of this 
type at the global level exists. In other words, the 
Global Transactions are over qualified for the 




Fig. 5. Factory application: An atomic application accesses 
several remote databases. 



example application. More precisely, the isolation 
between Global Transaction can be reduced. 

Reduced isolation at the global level leads 
immediately to well-known drawbacks. Let us as- 
sume that an application Al (Fig. 5) starts at 
server DB1 and orders the last available part 
there. At the same time application A2 may start 
at server DB2 and orders the last available part. 
In case Al and A2 have to make orders at nodes 
DB2 and DB1 respectively both are unsuccessful 
in the end. Compensating would be necessary 
whereas Global Transactions would have been 
aborted (because of a deadlock) if they would 
have been executed the same way. 

However in the latter variant of our example, 
database consistency can not be affected pro- 
vided all local applications are executed as local 
transactions. Thus we consider the above men- 
tioned drawback as comparatively small since 
node autonomy is improved and distributed dead- 
locks cannot occur by following this execution 
scheme. 

Isolation can be reduced only at the global but 
not at the local level. Locally each issued order 
(and the cancellation of orders) is a local transac- 
tion running under control of the local concur- 
rency mechanism in parallel to other subtransac- 
tions of Global Transactions or local transactions. 

The example shows that the need to execute 
this application in full isolation from others does 
not exist. We need to make sure that at each 
state of execution of applications the all or noth- 
ing property (atomicity) can be guaranteed. This 
is to be done by calling compensating applica- 
tions and, if at hand, alternative applications. 
Isolation would introduce some drawbacks: 
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1. other customers would have to wait for uncer- 
tain amount of time before being allowed to 
access the data requested, and 

2. communication links would have to be held for 
each node. 

However, not all types of applications should be 
executed with reduced isolation. For example, 
interleaved applications that compute the worth 
of all parts available need to be isolated from 
other applications. This is in order to guarantee 
that a stable global database state can be seen. 
Only this allows the making of a correct account 
that does not include orders of partially executed 
applications. In case this type of application would 
run with reduced isolation the client would get 
wrong results but still no consistency violation 
would occur since local databases would not be 
changed. In many cases (e.g. compute a rough 
estimate of the stock situation) a user might be 
statisfied with a result computed this way. 



?. Global Transaction Procedures (OTPs) 

We have shown that global applications in 
FDDBs need not always be executed under the 
restriction of guaranteeing global serializability. 
As the former example shows, certain applica- 
tions can be executed as atomic units without 
being isolated from each other at the global level. 
In case execution autonomy of nodes is an impor- 
tant design goal, reduced isolation at the global 
level would relax the drawbacks introduced by 
Global Transactions. 

A new model of a Global Transaction, the 
Global Transaction Trocedure (GTP) serves this 
purpose and will be introduced in the following. 

GTPs are based on Sagas. In [8] Sagas are 
introduced as a collection of intended subtransac- 
tions that can be interleaved in any way with 
other transactions. To ensure atomicity the au- 
thors require that compensating subtransactions 
(cST)-) are used (Fig. 6). 

Once compensating transactions, cST,, cST 2) 
. . . ,cST rt _ , are defined for Saga ST ( , ST 2 , . . . ,ST n , 
then the system can make the following guaran- 
tee: cither the sequence ST,, ST 2 ,...,ST n or the 
sec3uence ST It ST 2 , . . . ,STycST,-, . . . ,cST 2) cST, for 
some 1 <y < n will be executed [8]. 

The results of the subtransactions are made 
immediately visible for other Sagas when a sub- 



Nm: STj cS^j 
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Fig. 6. Compensating Subtransactions: STj produces an 
undesired result at node Nm. The subtransactions executed 
so far are compensated. 

transaction finishes execution. Since no 2 PC pro- 
tocol is used, the isolation between Sagas is re- 
stricted to isolation between subtransactions on 
local systems. 

In [17] Sagas are applied to federative dis- 
tributed database management systems. In our 
approach we extend the proposed model by: 
integrate it with the traditional model of dis- 
tributed transactions (Global Transactions) 
and 

2. integrate both into one database programming 

language DBPL [18,19]. 

In the following we will concentrate on the 
synchronization aspects by integrating both trans- 
action models into one system environment. Re- 
fer to [19] for the language aspects. 

In addition Global Transaction Procedures 
comprises alternative subtransactions. All sub- 
transactions are executed in a way that allows for 
order independent compensation of subtransac- 
tions. 

We will explain the mentioned properties of 
GTPs more detailed in the next paragraph. 

5.1. Alternative subtransaction 

In case a subtransaction is not available e.g. 
because of failures or inaccessible resources 
(nodes, databases etc.) we allow for the execution 
of alternative subtransactions [8]. 

This reflects the expected services of a FD- 
DBS. In an open system services may be repli- 
cated on different sender nodes. In case a sub- 
transaction aborts it is quite natural to look for a 
similar service (e.g. a flight is booked out and an 
alternative airline is taken). Alternative subtrans- 
actions remove the necessity of running compen- 
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Nm : STn 
STl 

STj-l 
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Fig. 1. Alternative Subtransactions: ST] produces an unde- 
sired result at node Nj. Instead of compensating already 
produced results the alternative subtransaction aSTj is exe- 
cuted automatically. 



sating subtransactions for those subsets of sub- 
transactions that are already completed success- 
fully (Fig, 7). Thus on average, a smaller set of 
compensating subtransactions have to be run, re- 
sulting in an increased throughput of intended 
subtransactions. The model requires that for each 
alternative subtransaction a compensating sub- 
transaction be provided. Thus an alternative sub- 
transaction can dealt with the same way as an 
intended subtransaction. 



5.2. Order independence 

Subtransactions belonging to GTPs should be 
treated as ordinary local transactions. Thus,.the 
isolation between GTPs is reduced. They commit 
immediately after finishing computing and make 
their results visible to other GTPs. However the 
execution of a GTP should obey certain consis- 
tency requirements. 

As already mentioned, in our model GTPs are 
built out of subtransactions exported by server 
databases forming the FDDBS. Exportation of 
subtransactions refers to the decision of the 
database (human) administrator of a certain ad- 
ministrative area to make a set of prepared sub- 
transactions accessible for remote users. The ad- 
ministration of server databases offer only such 
subtransactions to be imported into a GTP that 
fulfill basically the following property: 
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Let OTP, = {ST,,, cST lj5 ST M> ,. ..} ;ind GTP, 
= {ST 2al cST 2ilt ST 2b ,...} be GTPs consisting of 
subtransactions ST M to be executed on nodes N ; . 
Then the administration of a node Nj allows only 
those subtransactions to be exported into GTPs 
that are order independent. 

ST l; — ST 2; ^cST 2 , 

ST 2j -> cST 2j -» ST„ 
<=► 

ST,,- - ST„-cST 2 , 

ST,; 

The above implies that the final outcome is inde- 
pendent of the order in which the intended sub- 
transactions and compensating subtransactions 
are executed. The result left within the database 
has to be the same as if the intended subtransac- 
tion ST,,- were executed alone. Note that it is not 
allowed for a compensating subtransaction to be 
executed in precedence to its intended counter- 
part. 

However a drawback of the usage of GTPs 
should be mentioned here: The (human) database 
administrator responsible for the semantics of 
exported subtransactions has to make sure that 
the order independence of all exported subtrans- 
actions is valid. Therefore order independence 
usually is reachable only for certain 'simple* se- 
mantics of subtransactions and thus only a subset 
of database applications can be executed under 
this assumption. 

Order independence is of local matter to the 
server nodes and thus only subtransactions of a 
certain server are considered by proving this cri- 
terion. 

We have to take into account that order inde- 
pendence can not be proved in most cases. This is 
because most applications do not allow order 
independent executions in arbitrary order. In ad- 
dition for complex applications it would often 
mean an unacceptable amount of work to prove 
this condition. Instead the administrator has to 
run tests of interleaving conflicting subtransac- 
tions and compensating subtransactions. 

The advantage of order independence is that 
an administrator controls the semantics executed 
by GTPs on his node. By exporting subtransac- 
tion into Global Transaction Procedures he is 
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provided with a higher degree of node autonomy 
without loosing the control of local consistency. 

5.3. Synchronizing GTs and GTPs 

In this paragraph we give an outline how the 
integration of both transaction models is done. 
Our approach to increasing node autonomy re- 
stricts applications to global semantic atomicity 
where possible. Global Transactions are only used 
where necessary [19]. 

The main advantage of this approach is to 
provide the user with the freedom to make a 
choice of an appropriate execution support. Of 
course this is restricted to a certain extent. The 
main restriction concerns the semantics of appli- 
cations executed with semantic atomicity. Since 
no global serializabiliry is provided the applica- 
tions have to be selected carefully. The second 
restriction concerns the right to define the se- 
mantics of that class of applications by program- 
ming the subtransactions to be exported. We will 
assume that only the provider of a database ser- 
vice is allowed to define the semantic of 
(sub)transactions exported to GTPs. 

The main goal for the synchronization of GT 
and GTP in one environment is to prevent GT 
from reading data written by subtransactions of 
GTPs that are active concurrently. If this would 
be allowed the data read is in danger of being the 
subject of a later compensating subtransaction. 
This data therefore can be seen as 'dirty data' 
since subtransactions of a GT are not executed to 
be order independent. In case GTs would be 
allowed to read this data, the problem of cascad- 
ing rollbacks would arise. 

We enforce the synchronization of GT and 
GTP by checking whether or not GTs or GTPs 
are active on data to be accessed. This requires 
that GTPs announce themselves before beginning 
a subtransaction at a certain node. The active 
state is relevant to the data scope being accessed. 
Thus precl aiming (for subtransactions of GTPs 
only) is used to define the scope to be accessed in 
advance. A GTP is deactivated by a message after 
the last subtransaction of this GTP is executed 
successfully. This procedure provides for a mu- 
tual exclusion of GT and GTP when conflicting 
data is concerned. The main goal for synchroniza- 
tion is: GT must not read data that can be subject 



c £ 
announce (GTP-Iei , scope ) 



complete { GTP- Id) 



Fig. 8. Announcement 2nd Completion of GTP: A Client (C) 
announces a subtransaction of a GTP by identifying the GTP 
wrth an unique GTP-ID. In addition, the scope of data to be 
accessed is announced at server S. The GTP is deactivated 
at S when a complete has been received, signaling that alt 
subtransactions of that particular GTP are successfully fin- 
ished. 

to compensating transactions. To reach that goal 
the following rules are introduced: 

1. Intended subtransactions of GTs and GTPs 
are announced to nodes to be accessed (Fig. 
81 

2. Conflicting subtransactions are detected by 
scope descriptions of the announce message. 

3. Data written by active GTPs can be read only 
by other active GTPs. 

4. Data written by active GTPs can not be read 
by active GTs (and vice versa). 

5. GTP waits for completion of conflicting GTs 
(and vice versa). 

6. Completion of GTPs is announced to nodes 
concerned. 

Failures of GTPs or unsuccessful subtransactions 
are dealt with by calling alternative or compensat- 
ing subtransactions. The latter case requires de- 
activating subtransactions at each node con- 
cerned. 

Since we know that 2PL/2PC provides for 
global serializability, all applications running 
within that synchronization/ recovery technique 
are correct. 

On the other hand all GTPs are build out of 
subtransactions that are locally order indepen- 
dent. 

The combination of both avoids the reading of 
dirty data by subtransactions of GT. Thus all 
executions of GTs are correct. 

Note that correctness means that local 
databases are always in a consistent state. This is 
guaranteed by the fact that all subtransactions of 
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GT and GTP urc handled by the Inca! concur- 
rency control mechanism. Moreover from a global 
viewpoint order independence guarantees that all 
compensating subtransactions will compensate the 
effects of their intended subtransaction counter- 
parts. 

From a global viewpoint the user has to con- 
sider whcihcr the subtransactions exported by 
server nodes are sufficient for his task then exe- 
cuted by a Global Transaction Procedure. Other- 
wise he has to select the Global Transaction for 
his purposes. 

6. Conclusion 

Since both the transaction models of type GT 
and GTP introduced in this paper, show some 
drawbacks, we have proposed their combination 
into one environment. 

The potential user therefore can chose (within 
the limits shown) between two models of transac- 
tions. Furthermore, the server administrator is 
able to chose whether he wants to open his 
database for unrestricted use by remote users, or 
restrict the application to prepared subtransac- 
tions as part of Global Transaction Procedures 
with reduced isolation properties. The latter will 
provide him with a higher degree of autonomy. 
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